System, method and article of manufacture for secure network electronic payment and credit collection

ABSTRACT

Secure transmission of data is provided between a plurality of computer systems over a public communication system, such as the Internet. Secure transmission of data is provided from a customer computer system to a merchant computer system, and for the further secure transmission of data from the merchant computer system to a payment gateway computer system. The payment gateway system evaluates the information and returns authorization or denial of credit via a secure transmission to the merchant which is communicated to the customer by the merchant.

FIELD OF THE INVENTION

[0001] The present invention relates to the electronic payment inexchange for goods and services purchased over a communication network,and more specifically, and more particularly, to a system, method andarticle of manufacture for securely transmitting payment informationfrom a customer to a merchant to a payment gateway and returningappropriate, secure authorization to the merchant and the customer.

BACKGROUND OF THE INVENTION

[0002] It is desirable for a computer operated under the control of amerchant to obtain information offered by a customer and transmitted bya computer operating under the control of the customer over a publiclyaccessible packet-switched network (e.g., the Internet) to the computeroperating under the control of the merchant, without risking theexposure of the information to interception by third parties that haveaccess to the network, and to assure that the information is from anauthentic source. It is further desirable to have the ability for themerchant to transmit information, including a subset of the informationprovided by the customer, over such a network to a payment gatewaycomputer system that is authorized, by a bank or other financialinstitution that has the responsibility of providing payment on behalfof the customer, to authorize a commercial transaction on behalf of sucha financial institution, without the risk of exposing that informationto interception by third parties. Such institutions include, forexample, financial institutions offering credit or debit card services.

[0003] One such attempt to provide such a secure transmission channel isa secure payment technology such as Secure Electronic Transaction(hereinafter “SET”), jointly developed by the Visa and MasterCard cardassociations, and described in Visa and MasterCard's Secure ElectronicTransaction (SET) Specification, Feb. 23, 1996, hereby incorporated byreference. Other such secure payment technologies include SecureTransaction Technology “STT”), Secure Electronic Payments Protocol(“SEPP”), Internet Keyed Payments (“iKP”), Net Trust, and CybercashCredit Payment Protocol. One of ordinary skill in the art will readilycomprehend that any of the secure payment technologies can besubstituted for the SET protocol without undue experimentation. Suchsecure payment technologies require the customer to operate softwarethat is compliant with the secure payment technology, interacting withthird-party certification authorities, thereby allowing the customer totransmit encoded information to a merchant, some of which may be decodedby the merchant, and some which can be decoded only by a payment gatewayspecified by the customer. A drawback to the secure payment technologyapproach is that it requires deployment of special-purpose softwarecompliant with the particular secure payment technology to the customer,thereby limiting user acceptance of the secure payment technology tothose customers willing to install that software. Customers aregenerally reluctant to install such specialized software in the absenceof a general acceptance of merchant software and payment gatewaysoftware that incorporate the corresponding secure payment technologywith which to interact. Similarly, merchants and payment gateways arereluctant to implement a secure payment technology in the absence of aninstalled customer base that is available to use that secure paymenttechnology. This presents a “chicken-and-the-egg” problem in that noparticular component of a secure payment technology is likely to achievegeneral acceptance until the other components also achieve generalacceptance.

[0004] Another such attempt to provide such a secure transmissionchannel is a general-purpose secure communication protocol such asNetscape, Inc.'s Secure Sockets Layer (hereinafter “SSL”), as describedin Freier, Karlton & Kocher (hereinafter “Freier”), The SSL ProtocolVersion 3.0, March 1996, and hereby incorporated by reference. SSLprovides a means for secure transmission between two computers. SSL hasthe advantage that it does not require special-purpose software to beinstalled on the customer's computer because it is already incorporatedinto widely available software that many people utilize as theirstandard Internet access medium, and does not require that the customerinteract with any third-party certification authority. Instead, thesupport for SSL may be incorporated into software already in use by thecustomer, e.g., the Netscape Navigator World Wide Web browsing tool.However, although a computer on an SSL connection may initiate a secondSSL connection to another computer, a drawback to the SSL approach iseach SSL connection supports only a two-computer connection. Therefore,SSL does not provide a mechanism for transmitting encoded information toa merchant for retransmission to a payment gateway such that a subset ofthe information is readable to the payment gateway but not to themerchant. Although SSL allows for robustly secure two-party datatransmission, it does not meet the ultimate need of the electroniccommerce market for robustly secure three-party data transmission. Otherexamples of general-purpose secure communication protocols includePrivate Communications Technology (“PCT”) from Microsoft, Inc., SecureHyper-Text Transport Protocol (“SHTTP”) from Theresa Systems, Shen,Kerberos, Photuris, Pretty Good Privacy (“PGP”) and Ipv6 which meets theIPSEC criteria. One of ordinary skill in the art will readily comprehendthat any of the general-purpose secure communication protocols can besubstituted for the SSL transmission protocol without undueexperimentation.

OBJECTS OF THE INVENTION

[0005] It is desirable to provide a hybrid approach that encourages thedeployment of a three-party secure channel such as SET by paymentgateways in the absence of customer acceptance, thereby providingcustomers with an incentive to install SET-compliant software on theircomputer systems. It is further desirable to provide a means by which amerchant may communicate with a customer using a readily deployed securechannel such SSL or another general-purpose secure communicationprotocol, and communicate with a payment gateway using a modifiedSET-like protocol that is not dependent upon customer certification.

SUMMARY OF THE INVENTION

[0006] According to a broad aspect of a preferred embodiment of theinvention, secure transmission of data is provided between a pluralityof computer systems over a public communication system, such as theInternet. Secure transmission of data is provided from a customercomputer system to a merchant computer system, and for the furthersecure transmission of data from the merchant computer system to apayment gateway computer system. The payment gateway system evaluatesthe information and returns authorization or denial of credit via asecure transmission to the merchant which is communicated to thecustomer by the merchant.

DESCRIPTION OF THE DRAWINGS

[0007] The foregoing and other objects, aspects and advantages arebetter understood from the following detailed description of a preferredembodiment of the invention with reference to the drawings, in which:

[0008]FIG. 1A is a block diagram of a representative hardwareenvironment in accordance with a preferred embodiment;

[0009]FIG. 1B depicts an overview in accordance with a preferredembodiment;

[0010]FIG. 2 depicts a more detailed view of a customer computer systemin communication with merchant system under the Secure Sockets Layerprotocol in accordance with a preferred embodiment;

[0011]FIG. 3 depicts an overview of the method of securely supplyingpayment information to a payment gateway in order to obtain paymentauthorization in accordance with a preferred embodiment;

[0012]FIG. 4 depicts the detailed steps of generating and transmitting apayment authorization request in accordance with a preferred embodiment;

[0013]FIGS. 5A through 5F depict views of the payment authorizationrequest and its component parts in accordance with a preferredembodiment;

[0014]FIGS. 6A and 6B depict the detailed steps of processing a paymentauthorization request and generating and transmitting a paymentauthorization request response in accordance with a preferredembodiment;

[0015]FIGS. 7A through 7J depict views of the payment authorizationresponse and its component parts in accordance with a preferredembodiment;

[0016]FIG. 8 depicts the detailed steps of processing a paymentauthorization response in accordance with a preferred embodiment;

[0017]FIG. 9 depicts an overview of the method of securely supplyingpayment capture information to a payment gateway in accordance with apreferred embodiment;

[0018]FIG. 10 depicts the detailed steps of generating and transmittinga payment capture request in accordance with a preferred embodiment;

[0019]FIGS. 11A through 11F depict views of the payment capture requestand its component parts in accordance with a preferred embodiment;

[0020]FIGS. 12A and 12B depict the detailed steps of processing apayment capture request and generating and transmitting a paymentcapture request response in accordance with a preferred embodiment;

[0021]FIGS. 13A through 13F depict views of the payment capture responseand its component parts in accordance with a preferred embodiment; and

[0022]FIG. 14 depicts the detailed steps of processing a payment captureresponse in accordance with a preferred embodiment.

DETAILED DESCRIPTION

[0023] A preferred embodiment of a system in accordance with the presentinvention is preferably practiced in the context of a personal computersuch as the IBM PS/2, Apple Macintosh computer or UNIX basedworkstation. A representative hardware environment is depicted in FIG.1A, which illustrates a typical hardware configuration of a workstationin accordance with a preferred embodiment having a central processingunit 10, such as a microprocessor, and a number of other unitsinterconnected via a system bus 12. The workstation shown in FIG. 1Aincludes a Random Access Memory (RAM) 14, Read Only Memory (ROM) 16, anI/O adapter 18 for connecting peripheral devices such as disk storageunits 20 to the bus 12, a user interface adapter 22 for connecting akeyboard 24, a mouse 26, a speaker 28, a microphone 32, and/or otheruser interface devices such as a touch screen (not shown) to the bus 12,communication adapter 34 for connecting the workstation to acommunication network (e.g., a data processing network) and a displayadapter 36 for connecting the bus 12 to a display device 38. Theworkstation typically has resident thereon an operating system such asthe Microsoft Windows Operating System (OS), the IBM OS/2 operatingsystem, the MAC OS, or UNIX operating system. Those skilled in the artwill appreciate that the present invention may also be implemented onplatforms and operating systems other than those mentioned.

[0024] A preferred embodiment is written using JAVA, C, and the C++language and utilizes object oriented programming methodology. Objectoriented programming (OOP) has become increasingly used to developcomplex applications. As OOP moves toward the mainstream of softwaredesign and development, various software solutions will need to beadapted to make use of the benefits of OOP. A need exists for theseprinciples of OOP to be applied to a messaging interface of anelectronic messaging system such that a set of OOP classes and objectsfor the messaging interface can be provided.

[0025] OOP is a process of developing computer software using objects,including the steps of analyzing the problem, designing the system, andconstructing the program. An object is a software package that containsboth data and a collection of related structures and procedures. Sinceit contains both data and a collection of structures and procedures, itcan be visualized as a self-sufficient component that does not requireother additional structures, procedures or data to perform its specifictask. OOP, therefore, views a computer program as a collection oflargely autonomous components, called objects, each of which isresponsible for a specific task. This concept of packaging data,structures, and procedures together in one component or module is calledencapsulation.

[0026] In general, OOP components are reusable software modules whichpresent an interface that conforms to an object model and which areaccessed at run-time through a component integration architecture. Acomponent integration architecture is a set of architecture mechanismswhich allow software modules in different process spaces to utilize eachothers capabilities or functions. This is generally done by assuming acommon component object model on which to build the architecture.

[0027] It is worthwhile to differentiate between an object and a classof objects at this point. An object is a single instance of the class ofobjects, which is often just called a class. A class of objects can beviewed as a blueprint, from which many objects can be formed.

[0028] OOP allows the programmer to create an object that is a part ofanother object. For example, the object representing a piston engine issaid to have a composition-relationship with the object representing apiston. In reality, a piston engine comprises a piston, valves and manyother components; the fact that a piston is an element of a pistonengine can be logically and semantically represented in OOP by twoobjects.

[0029] OOP also allows creation of an object that “depends from” anotherobject. If there are two objects, one representing a piston engine andthe other representing a piston engine wherein the piston is made ofceramic, then the relationship between the two objects is not that ofcomposition. A ceramic piston engine does not make up a piston engine.Rather it is merely one kind of piston engine that has one morelimitation than the piston engine; its piston is made of ceramic. Inthis case, the object representing the ceramic piston engine is called aderived object, and it inherits all of the aspects of the objectrepresenting the piston engine and adds further limitation or detail toit. The object representing the ceramic piston engine “depends from” theobject representing the piston engine. The relationship between theseobjects is called inheritance.

[0030] When the object or class representing the ceramic piston engineinherits all of the aspects of the objects representing the pistonengine, it inherits the thermal characteristics of a standard pistondefined in the piston engine class. However, the ceramic piston engineobject overrides these ceramic specific thermal characteristics, whichare typically different from those associated with a metal piston. Itskips over the original and uses new functions related to ceramicpistons. Different kinds of piston engines will have differentcharacteristics, but may have the same underlying functions associatedwith it (e.g., how many pistons in the engine, ignition sequences,lubrication, etc.). To access each of these functions in any pistonengine object, a programmer would call the same functions with the samenames, but each type of piston engine may have different/overridingimplementations of functions behind the same name. This ability to hidedifferent implementations of a function behind the same name is calledpolymorphism and it greatly simplifies communication among objects.

[0031] With the concepts of composition-relationship, encapsulation,inheritance and polymorphism, an object can represent just aboutanything in the real world. In fact, our logical perception of thereality is the only limit on determining the kinds of things that canbecome objects in object-oriented software. Some typical categories areas follows:

[0032] Objects can represent physical objects, such as automobiles in atraffic-flow simulation, electrical components in a circuit-designprogram, countries in an economics model, or aircraft in anair-traffic-control system.

[0033] Objects can represent elements of the computer-user environmentsuch as windows, menus or graphics objects.

[0034] An object can represent an inventory, such as a personnel file ora table of the latitudes and longitudes of cities.

[0035] An object can represent user-defined data types such as time,angles, and complex numbers, or points on the plane.

[0036] With this enormous capability of an object to represent justabout any logically separable matters, OOP allows the software developerto design and implement a computer program that is a model of someaspects of reality, whether that reality is a physical entity, aprocess, a system, or a composition of matter. Since the object canrepresent anything, the software developer can create an object whichcan be used as a component in a larger software project in the future.

[0037] If 90% of a new OOP software program consists of proven, existingcomponents made from preexisting reusable objects, then only theremaining 10% of the new software project has to be written and testedfrom scratch. Since 90% already came from an inventory of extensivelytested reusable objects, the potential domain from which an error couldoriginate is 10% of the program. As a result, OOP enables softwaredevelopers to build objects out of other, previously built, objects.

[0038] This process closely resembles complex machinery being built outof assemblies and sub-assemblies. OOP technology, therefore, makessoftware engineering more like hardware engineering in that software isbuilt from existing components, which are available to the developer asobjects. All this adds up to an improved quality of the software as wellas an increased speed of its development.

[0039] Programming languages are beginning to fully support the OOPprinciples, such as encapsulation, inheritance, polymorphism, andcomposition-relationship. With the advent of the C++ language, manycommercial software developers have embraced OOP. C++ is an OOP languagethat offers a fast, machine-executable code. Furthermore, C++ issuitable for both commercial-application and systems-programmingprojects. For now, C++ appears to be the most popular choice among manyOOP programmers, but there is a host of other OOP languages, such asSmalltalk, common lisp object system (CLOS), and Eiffel. Additionally,OOP capabilities are being added to more traditional popular computerprogramming languages such as Pascal.

[0040] The benefits of object classes can be summarized, as follows:

[0041] Objects and their corresponding classes break down complexprogramming problems into many smaller, simpler problems.

[0042] Encapsulation enforces data abstraction through the organizationof data into small, independent objects that can communicate with eachother. Encapsulation protects the data in an object from accidentaldamage, but allows other objects to interact with that data by callingthe object's member functions and structures.

[0043] Subclassing and inheritance make it possible to extend and modifyobjects through deriving new kinds of objects from the standard classesavailable in the system. Thus, new capabilities are created withouthaving to start from scratch.

[0044] Polymorphism and multiple inheritance make it possible fordifferent programmers to mix and match characteristics of many differentclasses and create specialized objects that can still work with relatedobjects in predictable ways.

[0045] Class hierarchies and containment hierarchies provide a flexiblemechanism for modeling real-world objects and the relationships amongthem.

[0046] Libraries of reusable classes are useful in many situations, butthey also have some limitations. For example:

[0047] Complexity. In a complex system, the class hierarchies forrelated classes can become extremely confusing, with many dozens or evenhundreds of classes.

[0048] Flow of control. A program written with the aid of classlibraries is still responsible for the flow of control (i.e., it mustcontrol the interactions among all the objects created from a particularlibrary). The programmer has to decide which functions to call at whattimes for which kinds of objects.

[0049] Duplication of effort. Although class libraries allow programmersto use and reuse many small pieces of code, each programmer puts thosepieces together in a different way. Two different programmers can usethe same set of class libraries to write two programs that do exactlythe same thing but whose internal structure (i.e., design) may be quitedifferent, depending on hundreds of small decisions each programmermakes along the way. Inevitably, similar pieces of code end up doingsimilar things in slightly different ways and do not work as welltogether as they should.

[0050] Class libraries are very flexible. As programs grow more complex,more programmers are forced to reinvent basic solutions to basicproblems over and over again. A relatively new extension of the classlibrary concept is to have a framework of class libraries. Thisframework is more complex and consists of significant collections ofcollaborating classes that capture both the small scale patterns andmajor mechanisms that implement the common requirements and design in aspecific application domain. They were first developed to freeapplication programmers from the chores involved in displaying menus,windows, dialog boxes, and other standard user interface elements forpersonal computers.

[0051] Frameworks also represent a change in the way programmers thinkabout the interaction between the code they write and code written byothers. In the early days of procedural programming, the programmercalled libraries provided by the operating system to perform certaintasks, but basically the program executed down the page from start tofinish, and the programmer was solely responsible for the flow ofcontrol. This was appropriate for printing out paychecks, calculating amathematical table, or solving other problems with a program thatexecuted in just one way.

[0052] The development of graphical user interfaces began to turn thisprocedural programming arrangement inside out. These interfaces allowthe user, rather than program logic, to drive the program and decidewhen certain actions should be performed. Today, most personal computersoftware accomplishes this by means of an event loop which monitors themouse, keyboard, and other sources of external events and calls theappropriate parts of the programmer's code according to actions that theuser performs. The programmer no longer determines the order in whichevents occur. Instead, a program is divided into separate pieces thatare called at unpredictable times and in an unpredictable order. Byrelinquishing control in this way to users, the developer creates aprogram that is much easier to use. Nevertheless, individual pieces ofthe program written by the developer still call libraries provided bythe operating system to accomplish certain tasks, and the programmermust still determine the flow of control within each piece after it'scalled by the event loop. Application code still “sits on top of” thesystem.

[0053] Even event loop programs require programmers to write a lot ofcode that should not need to be written separately for everyapplication. The concept of an application framework carries the eventloop concept further. Instead of dealing with all the nuts and bolts ofconstructing basic menus, windows, and dialog boxes and then makingthese things all work together, programmers using application frameworksstart with working application code and basic user interface elements inplace. Subsequently, they build from there by replacing some of thegeneric capabilities of the framework with the specific capabilities ofthe intended application.

[0054] Application frameworks reduce the total amount of code that aprogrammer has to write from scratch. However, because the framework isreally a generic application that displays windows, supports copy andpaste, and so on, the programmer can also relinquish control to agreater degree than event loop programs permit. The framework code takescare of almost all event handling and flow of control, and theprogrammer's code is called only when the framework needs it (e.g., tocreate or manipulate a proprietary data structure).

[0055] A programmer writing a framework program not only relinquishescontrol to the user (as is also true for event loop programs), but alsorelinquishes the detailed flow of control within the program to theframework. This approach allows the creation of more complex systemsthat work together in interesting ways, as opposed to isolated programs,having custom code, being created over and over again for similarproblems.

[0056] Thus, as is explained above, a framework basically is acollection of cooperating classes that make up a reusable designsolution for a given problem domain. It typically includes objects thatprovide default behavior (e.g., for menus and windows), and programmersuse it by inheriting some of that default behavior and overriding otherbehavior so that the framework calls application code at the appropriatetimes.

[0057] There are three main differences between frameworks and classlibraries:

[0058] Behavior versus protocol. Class libraries are essentiallycollections of behaviors that you can call when you want thoseindividual behaviors in your program. A framework, on the other hand,provides not only behavior but also the protocol or set of rules thatgovern the ways in which behaviors can be combined, including rules forwhat a programmer is supposed to provide versus what the frameworkprovides.

[0059] Call versus override. With a class library, the code theprogrammer instantiates objects and calls their member functions. It'spossible to instantiate and call objects in the same way with aframework (i.e., to treat the framework as a class library), but to takefull advantage of a framework's reusable design, a programmer typicallywrites code that overrides and is called by the framework. The frameworkmanages the flow of control among its objects. Writing a programinvolves dividing responsibilities among the various pieces of softwarethat are called by the framework rather than specifying how thedifferent pieces should work together.

[0060] Implementation versus design. With class libraries, programmersreuse only implementations, whereas with frameworks, they reuse design.A framework embodies the way a family of related programs or pieces ofsoftware work. It represents a generic design solution that can beadapted to a variety of specific problems in a given domain. Forexample, a single framework can embody the way a user interface works,even though two different user interfaces created with the sameframework might solve quite different interface problems.

[0061] Thus, through the development of frameworks for solutions tovarious problems and programming tasks, significant reductions in thedesign and development effort for software can be achieved. A preferredembodiment of the invention utilizes HyperText Markup Language (HTML) toimplement documents on the Internet together with a general-purposesecure communication protocol for a transport medium between the clientand the merchant. HTML is a simple data format used to create hypertextdocuments that are portable from one platform to another. HTML documentsare SGML documents with generic semantics that are appropriate forrepresenting information from a wide range of domains. HTML has been inuse by the World-Wide Web global information initiative since 1990. HTMLis an application of ISO Standard 8879:1986 Information Processing Textand Office Systems; Standard Generalized Markup Language (SGML).

[0062] To date, Web development tools have been limited in their abilityto create dynamic Web applications which span from client to server andinteroperate with existing computing resources. Until recently, HTML hasbeen the dominant technology used in development of Web-based solutions.However, HTML has proven to be inadequate in the following areas:

[0063] Poor performance;

[0064] Restricted user interface capabilities;

[0065] Can only produce static Web pages;

[0066] Lack of interoperability with existing applications and data; and

[0067] Inability to scale.

[0068] Sun Microsystem's Java language solves many of the client-sideproblems by:

[0069] Improving performance on the client side;

[0070] Enabling the creation of dynamic, real-time Web applications; and

[0071] Providing the ability to create a wide variety of user interfacecomponents.

[0072] With Java, developers can create robust User Interface (UI)components. Custom “widgets” (e.g. real-time stock tickers, animatedicons, etc.) can be created, and client-side performance is improved.Unlike HTML, Java supports the notion of client-side validation,offloading appropriate processing onto the client for improvedperformance. Dynamic, real-time Web pages can be created. Using theabove-mentioned custom UI components, dynamic Web pages can also becreated. Sun's Java language has emerged as an industry-recognizedlanguage for “programming the Internet.” Sun defines Java as: “a simple,object-oriented, distributed, interpreted, robust, secure,architecture-neutral, portable, high-performance, multithreaded,dynamic, buzzword-compliant, general-purpose programming language. Javasupports programming for the Internet in the form ofplatform-independent Java applets.” Java applets are small, specializedapplications that comply with Sun's Java Application ProgrammingInterface (API) allowing developers to add “interactive content” to Webdocuments (e.g. simple animations, page adornments, basic games, etc.).Applets execute within a Java-compatible browser (e.g. NetscapeNavigator) by copying code from the server to client. From a languagestandpoint, Java's core feature set is based on C++. Sun's Javaliterature states that Java is basically “C++, with extensions fromObjective C for more dynamic method resolution”.

[0073] Another technology that provides similar function to JAVA isprovided by Microsoft and ActiveX Technologies, to give developers andWeb designers wherewithal to build dynamic content for the Internet andpersonal computers. ActiveX includes tools for developing animation, 3-Dvirtual reality, video and other multimedia content. The tools useInternet standards, work on multiple platforms, and are being supportedby over 100 companies. The group's building blocks are called ActiveXControls, small, fast components that enable developers to embed partsof software in hypertext markup language (HTML) pages. ActiveX Controlswork with a variety of programming languages including Microsoft VisualC++, Borland Delphi, Microsoft Visual Basic programming system and, inthe future, Microsoft's development tool for Java, code named “Jakarta.”ActiveX Technologies also includes ActiveX Server Framework, allowingdevelopers to create server applications. One of ordinary skill in theart will readily recognize that ActiveX could be substituted for JAVAwithout undue experimentation to practice the invention.

[0074]FIG. 1B depicts an overview of the present invention. Customercomputer system 120 is in communication with merchant computer system130. The customer-merchant session 150 operates under a general-purposesecure communication protocol such as the SSL protocol. Merchantcomputer system 130 is additionally in communication with paymentgateway computer system 140. A payment gateway is a system that provideselectronic commerce services in support of a bank or other financialinstitution, and that interfaces to the financial institution to supportthe authorization and capture of transactions. The customer-institutionsession 170 operates under a variant of a secure payment technology suchas the SET protocol, as described herein, referred to asMerchant-Originated Secure Electronic Transactions (“MOSET”), as is morefully described herein.

[0075] Customer-to-Merchant Communication

[0076]FIG. 2 depicts a more detailed view of customer computer system120 in communication with merchant system 130 using customer-merchantsession 150 operating under the SSL protocol as documented in Freier andincorporated by reference.

[0077] Customer computer system 120 initiates communication withmerchant computer system 130 using any well-known access protocol, e.g.,Transmission Control Protocol/Internet Protocol (“TCP/IP”). In thisimplementation, customer computer system 120 acts as a client andmerchant computer system 130 acts as a server. Customer computer system120 initiates communication by sending “client hello” message 210 to themerchant computer system 130. When a client first connects to a serverit is required to send the client hello message 210 as its firstmessage. The client can also send a client hello message 210 in responseto a hello request on its own initiative in order to renegotiate thesecurity parameters in an existing connection. The client hello messageincludes a random structure, which is used later in the protocol.Specifically, the random structure includes the current time and date instandard UNIX 32-bit format according to the sender's internal clock andtwenty-eight bytes of data generated by a secure random numbergenerator. The client hello message 210 further includes a variablelength session identifier. If not empty, the session identifier valueidentifies a session between the same client and server whose securityparameters the client wishes to reuse. The session identifier may befrom an earlier connection, the current connection, or another currentlyactive connection. It is useful to specify the current connection if theclient only wishes to update the random structures and derived values ofa connection. It is useful to specify another currently activeconnection if the client wishes to establish several simultaneousindependent secure connections to the same server without repeating thefull handshake protocol. Client hello message 210 further includes anindicator of the cryptographic algorithms supported by the client inorder of the client's preference, ordered according to clientpreference.

[0078] In response to client hello message 210, if merchant computersystem 130 wishes to correspond with customer computer system 120, itresponds with server hello message 215. If merchant computer system 130does not wish to communicate with customer computer system 120, itresponds with a message, not shown, indicating refusal to communicate.

[0079] Server hello message 215 includes a random structure, which isused later in the protocol. The random structure in server hello message215 is in the same format as, but has contents independent of, therandom structure in client hello message 210. Specifically, the randomstructure includes the current time and date in standard UNIX 32-bitformat according to the sender's internal clock and twenty-eight bytesof data generated by a secure random number generator. Server hellomessage 215 further includes a variable length session identifier. Thesession identifier value identifies a new or existing session betweenthe same client and server. Server hello message 215 further includes anindicator of the cryptographic algorithms selected from among thealgorithms specified by client hello message 210, which will be used infurther encrypted communications.

[0080] Optionally, Merchant computer system 130 transmits a servercertificate 220. If transmitted, server certificate 130 enables customercomputer system 120 to authenticate the identity of merchant computersystem 130.

[0081] If merchant computer system 130 does not transmit a servercertificate 220, or if server certificate 220 is suitable only forauthentication, it may optionally transmit a server key exchange message225. Server key exchange message 225 identifies a key that may be usedby customer computer system 120 to decrypt further messages sent bymerchant computer system 130.

[0082] After transmitting server hello message 215, and optionallytransmitting server certificate 220 or server key exchange message 225,merchant computer system 130 transmits a server hello done message 230and waits for a further response from customer computer system 120.

[0083] Customer computer system 120 optionally transmits clientcertificate 240 to merchant computer system 130. If transmitted, clientcertificate 240 enables merchant computer system 130 to authenticate theidentity of customer computer system 120. Alternatively, customercomputer system 120 may transmit a no-client-certificate alert 245, toindicate that the customer has not registered with any certificationauthority.

[0084] If customer computer system 130 does not transmit a clientcertificate 240, or if client certificate 240 is suitable only forauthentication, customer computer system 130 may optionally transmit aclient key exchange message 250. Client key exchange message 250identifies a key that may be used by merchant computer system 130 todecrypt further messages sent by customer computer system 120.

[0085] After optionally transmitting client certificate 240,no-client-certificate alert 245, and/or client key exchange message 250,customer computer system 120 transmits a finished message 260.

[0086] At this point, customer computer system 120 and merchant computersystem 130 have:

[0087] 1) negotiated an encryption scheme that may be commonly employedin further communications, and

[0088] 2) have communicated to each other a set of encryption keys thatmay be used to decrypt further communications between the two computersystems.

[0089] Customer computer system 120 and merchant computer system 130 maythereafter engage in secure communications 270 with less risk ofinterception by third parties.

[0090] Among the messages communicated by customer computer system 120to merchant computer system 130 may be messages that specify goods orservices to be ordered and payment information, such as a credit cardnumber and related information, collectively referred to as “paymentinformation,” that may be used to pay for the goods and/or servicesordered. In order to obtain payment, the merchant must supply thisinformation to the bank or other payment gateway responsible for theproffered payment method. This enables the merchant to perform paymentauthorization and payment capture. Payment authorization is the processby which permission is granted by a payment gateway operating on behalfof a financial institution to authorize payment on behalf of thefinancial institution. This is a process that assesses transaction risk,confirms that a given transaction does not raise the account holder'sdebt above the account's credit limit, and reserves the specified amountof credit. Payment capture is the process that triggers the movement offunds from the financial institution to the merchant's account.

[0091] Payment Authorization

[0092]FIG. 3 depicts an overview of the method of securely supplyingpayment information to a payment gateway in order to obtain paymentauthorization. In function block 310, merchant computer system 130generates a payment authorization request 315 and transmits it topayment gateway computer system 140. In function block 330, paymentgateway system 140 processes the payment authorization request,generates a payment authorization response 325 and transmits it tomerchant computer system 130. In function block 320, merchant computersystem 130 processes payment authorization response 325 and determineswhether payment for the goods or services sought to be obtained by thecustomer has been authorized.

[0093] Payment Authorization Request Generation

[0094]FIG. 4 depicts the detailed steps of generating and transmitting apayment authorization request. FIGS. 5A through 5F depict views of thepayment authorization request and its component parts. In function block410, merchant computer system 130 creates a basic authorization request510. The basic authorization request is a data area that includes allthe information for determining whether a request should be granted ordenied. Specifically, it includes such information as the party who isbeing charged, the amount to be charged, the account number of theaccount to be charged, and any additional data, such as passwords,needed to validate the charge.

[0095] This information is either calculated based upon prior customermerchandise selection, or provided by the customer over the secure link270 established in the customer-merchant general-purpose securecommunication protocol session. FIG. 5A depicts a basic authorizationrequest 510.

[0096] In function block 420, merchant computer system 130 combinesbasic authorization request 510, a copy of its encryption public keycertificate 515 and a copy of its signature public key certificate 520.Merchant computer system 130 calculates a digital signature 525 for thecombined contents of the combined block 530 comprising basicauthorization request 510, the encryption public key certificate 515 andthe signature public key certificate 520, and appends it to thecombination of the combined basic authorization request 510, theencryption public key certificate 515 and the signature public keycertificate 520. The merchant computer system calculates digitalsignature 525 by first calculating a “message digest” based upon thecontents of the combined basic authorization request 510, the encryptionpublic key certificate 515 and the signature public key certificate 520.A message digest is the fixed-length result that is generated when avariable length message is fed into a one-way hashing function. Messagedigests help verify that a message has not been altered because alteringthe message would change the digest. The message digest is thenencrypted using the merchant computer system's 130 digital signatureprivate key, thus forming a digital signature.

[0097]FIG. 5B depicts the combined block 530 formed by function block420 and containing basic authorization request 510, the encryptionpublic key certificate 515, the signature public key certificate 520,and digital signature 525.

[0098] In function block 430, merchant computer system 130 generates arandom encryption key RK-0 540, denoted as RK-0. Random encryption keyRK-0 540 is a symmetric encryption key. A symmetric encryption key is akey characterized by the property that a message encrypted with asymmetric key can be decrypted with that same key. This is contrastedwith an asymmetric key pair, such as a public-key/private-key key pair,where a message encrypted with one key of the key pair may only bedecrypted with the other key of the same key pair. FIG. 5C depictsrandom encryption key RK-0 540.

[0099] In function block 440, merchant computer system 130 encryptscombined block 530 using random encryption key RK-0 540 to formencrypted combined block 550. FIG. 5D depicts encrypted combined block550. The encryption state of encrypted combined block 550 is graphicallyshown by random key lock 555, which indicates that encrypted combinedblock 550 is encrypted using random key RK-0 540.

[0100] In function block 450, merchant computer system 130 encryptsrandom encryption key RK-0 540 using the public key of payment gatewaysystem 140 to form encrypted random key 560. FIG. 5E depicts encryptedrandom key 560. The encryption state of encrypted random key 560 isgraphically shown by payment gateway public key lock 565, whichindicates that encrypted random key 560 is encrypted using the paymentgateway public key.

[0101] In function block 460, merchant computer system 130 concatenatesencrypted combined block 550 and encrypted random key 560 to formmerchant authorization request 315. FIG. 5F depicts merchantauthorization request 315 comprising encrypted combined block 550 andencrypted random key 560. In function block 470, merchant computersystem 130 transmits merchant authorization request 315 to paymentgateway system 140.

[0102] Payment Authorization Request Processing

[0103]FIG. 6 depicts the detailed steps of processing a paymentauthorization request and generating and transmitting a paymentauthorization request response. Function blocks 610 through 630 depictthe steps of processing a payment authorization request, while functionblocks 635 through 685 depict the steps of generating and transmitting apayment authorization request response.

[0104] In function block 610, payment gateway computer system 140applies its private key to encrypted random key 560 contained withinreceived merchant authorization request 315, thereby decrypting it andobtaining a cleartext version of random key RK-0 540. In function block615, payment gateway computer system 140 applies random key RK-0 540 toencrypted combined block 550, thereby decrypting it and obtaining acleartext version of combined block 530. It will be recalled thatcombined block 530 comprises basic authorization request 510, a copy ofmerchant computer system's 130 encryption public key certificate 515 anda copy of merchant computer system's 130 signature public keycertificate 520, as well as merchant digital signature 525.

[0105] In function block 620, payment gateway computer system 140verifies merchant computer system's 130 encryption public keycertificate 515 and merchant computer system's 130 signature public keycertificate 520. Payment gateway computer system 140 performs thisverification by making a call to the certification authoritiesassociated with each certificate. If verification of either certificatefails, payment gateway computer system 140 rejects the authorizationrequest.

[0106] In function block 625, payment gateway computer system 140validates merchant digital signature 525. Payment gateway computersystem 140 performs this validation by calculating a message digest overthe contents of the combined basic authorization request 510, theencryption public key certificate 515 and the signature public keycertificate 520. Payment gateway computer system 140 then decryptsdigital signature 525 to obtain a copy of the equivalent message digestcalculated by merchant computer system 130 in function block 420. If thetwo message digests are equal, the digital signature 525 is validated.If validation fails, payment gateway computer system 140 rejects theauthorization request.

[0107] In function block 630, payment gateway computer system 140determines the financial institution for which authorization is requiredby inspection of basic authorization request 510. Payment gatewaycomputer system 140 contacts the appropriate financial institution usinga secure means, e.g, a direct-dial modem-to-modem connection, or aproprietary internal network that is not accessible to third parties,and using prior art means, obtains a response indicating whether therequested payment is authorized.

[0108] Payment Authorization Response Generation

[0109] Function blocks 635 through 685 depict the steps of generatingand transmitting a payment authorization request response. FIGS. 7Athrough 7J depict views of the payment authorization response and itscomponent parts.

[0110] In function block 635, payment gateway computer system 140creates a basic authorization response 710. The basic authorizationrequest is a data area that includes all the information to determinewhether a request was granted or denied. FIG. 7A depicts basicauthorization response 710.

[0111] In function block 640, payment gateway computer system 140combines basic authorization response 710, and a copy of its signaturepublic key certificate 720. Payment computer system 140 calculates adigital signature 725 for the combined contents of the combined block730 comprising basic authorization response 710 and the signature publickey certificate 720, and appends the signature to the combination of thecombined basic authorization response 710 and the signature public keycertificate 720. The payment gateway computer system calculates digitalsignature 725 by first calculating a message digest based on thecontents of the combined basic authorization response 710 and signaturepublic key certificate 720. The message digest is then encrypted usingthe merchant computer system's 140 digital signature private key, thusforming a digital signature.

[0112]FIG. 7B depicts the combined block 730 formed in function block640 and containing basic authorization response 710, the signaturepublic key certificate 720, and digital signature 725.

[0113] In function block 645, payment gateway computer system 150generates a first symmetric random encryption key 740, denoted as RK-1.FIG. 7C depicts first random encryption key RK-1 740.

[0114] In function block 650, payment gateway computer system 140encrypts combined block 730 using random encryption key RK-1 740 to formencrypted combined block 750. FIG. 7D depicts encrypted combined block750. The encryption state of encrypted combined block 750 is graphicallyshown by random key lock 755, which indicates that encrypted combinedblock 750 is encrypted using random key RK-1 740.

[0115] In function block 655, payment gateway computer system 140encrypts random encryption key RK-1 740 using the public key of merchantcomputer system 130 to form encrypted random key RK 760. FIG. 7E depictsencrypted random key RK-1 760. The encryption state of encrypted randomkey 760 is graphically shown by merchant public key lock 765, whichindicates that encrypted random key 760 is encrypted using the merchantpublic key.

[0116] In function block 660, payment gateway computer system 140generates a random capture token 770. Random capture token 770 will beused in subsequent payment capture processing to associate the paymentcapture request with the payment authorization request being processed.FIG. 7F depicts capture token 775.

[0117] In function block 665, payment gateway computer system 140generates a second symmetric random encryption key 775, denoted as RK-2.FIG. 7G depicts second random encryption key RK-2 775.

[0118] In function block 670, payment gateway computer system 140encrypts capture token 770 using random encryption key RK-2 770 to formencrypted capture token 780. FIG. 7H depicts encrypted capture token780. The encryption state of encrypted capture token 780 is graphicallyshown by random key lock 785, which indicates that encrypted capturetoken 780 is encrypted using random key RK-2 770.

[0119] In function block 675, payment gateway computer system 140encrypts second random encryption key RK-2 775 using its own public keyto form encrypted random key RK-2 790. FIG. 71 depicts encrypted randomkey RK-2 790. The encryption state of encrypted random key 790 isgraphically shown by payment gateway public key lock 795, whichindicates that encrypted random key 790 is encrypted using the paymentgateway public key.

[0120] In function block 680, payment gateway computer system 140concatenates encrypted combined block 750, encrypted random key RK-1760, encrypted capture token 780 and encrypted random key RK-2 790 toform merchant authorization response 325. FIG. 7J depicts merchantauthorization response 325 comprising encrypted combined block 750,encrypted random key RK-1 760, encrypted capture token 780 and encryptedrandom key RK2 790. In function block 685, payment gateway computersystem 140 transmits merchant authorization response 325 to merchantsystem 130.

[0121] Payment Authorization Response Processing

[0122]FIG. 8 depicts the detailed steps of processing a paymentauthorization response. In function block 810, merchant computer system130 applies its private key to encrypted random key RK-1 760 containedwithin received merchant authorization response 325, thereby decryptingit and obtaining a cleartext version of random key RK-1 740.

[0123] In function block 820, merchant computer system 130 appliesrandom key RK-1 740 to encrypted combined block 750, thereby decryptingit and obtaining a cleartext version of combined block 730. It will berecalled that combined block 730 comprises basic authorization response710, a copy of payment gateway computer system's 140 signature publickey certificate 720, as well as payment gateway digital signature 725.

[0124] In function block 830, merchant computer system 130 verifiespayment gateway computer system's 140 signature public key certificate720. Merchant computer system 130 performs this verification by making acall to the certification authority associated with the certificate. Ifverification of the certificate fails, merchant computer system 130concludes that the authorization response is counterfeit and treats itthough the authorization request had been rejected.

[0125] In function block 840, merchant computer system 130 validatespayment gateway digital signature 725. Merchant computer system 130performs this validation by calculating a message digest over thecontents of the combined basic authorization request 710 and thesignature public key certificate 720. Merchant computer system 130 thendecrypts digital signature 725 to obtain a copy of the equivalentmessage digest calculated by payment gateway computer system 140 infunction block 640. If the two message digests are equal, the digitalsignature 725 is validated. If validation fails, concludes that theauthorization response is counterfeit and treats it though theauthorization request had been rejected.

[0126] In function block 850, merchant computer system 130 storesencrypted capture token 780 and encrypted random key RK-2 790 for lateruse in payment capture. In function block 860, merchant computer system130 processes the customer purchase request in accordance with theauthorization response 710. If the authorization response indicates thatpayment in authorized, merchant computer system 130 fills the requestedorder. If the authorization response indicates that payment is notauthorized, or if merchant computer system 130 determined in functionblock 830 or 840 that the authorization response is counterfeit,merchant computer system 130 indicates to the customer that the ordercannot be filled.

[0127] Payment Capture

[0128]FIG. 9 depicts an overview of the method of securely supplyingpayment capture information to payment gateway 140 in order to obtainpayment capture. In function block 910, merchant computer system 130generates a merchant payment capture request 915 and transmits it topayment gateway computer system 140. In function block 930, paymentgateway system 140 processes the payment capture request 915, generatesa payment capture response 925 and transmits it to merchant computersystem 130. In function block 920, merchant computer system 130processes payment capture response 925 and verifies that payment for thegoods or services sought to be obtained by the customer have beencaptured.

[0129] Payment Capture Request Generation

[0130]FIG. 10 depicts the detailed steps of generating and transmittinga payment capture request. FIGS. 11A through 11F depict views of thepayment capture request and its component parts. In function block 1010,merchant computer system 130 creates a basic capture request 510. Thebasic capture request is a data area that includes all the informationneeded by payment gateway computer system 140 to trigger a transfer offunds to the merchant operating merchant computer system 130.

[0131] Specifically, a capture request includes a capture requestamount, a capture token, a date, summary information of the purchaseditems and a Merchant ID (MID) for the particular merchant. FIG. 11Adepicts basic authorization request 1110.

[0132] In function block 1020, merchant computer system 130 combinesbasic capture request 1110, a copy of its encryption public keycertificate 1115 and a copy of its signature public key certificate1120. Merchant computer system 130 calculates a digital signature 1125for the combined contents of the combined block 1130 comprising basiccapture request 1110, the encryption public key certificate 1115 and thesignature public key certificate 1120, and appends it to the combinationof the combined basic capture request 1110, the encryption public keycertificate 1115 and the signature public key certificate 1120. Themerchant computer system calculates digital signature 1125 by firstcalculating a message digest over the contents of the combined basiccapture request 1110, the encryption public key certificate 1115 and thesignature public key certificate 1120. The message digest is thenencrypted using the merchant computer system's 130 digital signatureprivate key, thus forming a digital signature.

[0133]FIG. 11B depicts the combined block 1130 formed by function block1020 and containing basic capture request 1110, the encryption publickey certificate 1115, the signature public key certificate 1120, anddigital signature 1125.

[0134] In function block 1030, merchant computer system 130 generates arandom encryption key 1140, denoted as RK-3. Random encryption key RK-31140 is a symmetric encryption key. FIG. 11C depicts random encryptionkey RK-3 1140.

[0135] In function block 1040, merchant computer system 130 encryptscombined block 1130 using random encryption key RK-3 1140 to formencrypted combined block 1150. FIG. 11D depicts encrypted combined block1150. The encryption state of encrypted combined block 1150 isgraphically shown by random key lock 1155, which indicates thatencrypted combined block 1150 is encrypted using random key RK-3 1140.

[0136] In function block 1050, merchant computer system 130 encryptsrandom encryption key RK-3 1140 using the public key of payment gatewaysystem 140 to form encrypted random key 1160. FIG. 11E depicts encryptedrandom key 1160. The encryption state of encrypted random key 1160 isgraphically shown by payment gateway public key lock 1165, whichindicates that encrypted random key RK-3 1160 is encrypted using thepayment gateway public key.

[0137] In function block 1060, merchant computer system 130 concatenatesencrypted combined block 1150, encrypted random key 1160, and theencrypted capture token 780 and encrypted random key RK-2 790 that werestored in function block 850 to form merchant capture request 915. FIG.11F depicts merchant capture request 915, comprising encrypted combinedblock 1150, encrypted random key 1160, encrypted capture token 780 andencrypted random key RK-2 790. In function block 1070, merchant computersystem 130 transmits merchant capture request 915 to payment gatewaysystem 140.

[0138] Payment Capture Request Processing

[0139]FIG. 12 depicts the detailed steps of processing a payment capturerequest and generating and transmitting a payment capture requestresponse. Function blocks 1210 through 1245 depict the steps ofprocessing a payment capture request, while function blocks 1250 through1285 depict the steps of generating and transmitting a payment capturerequest response.

[0140] In function block 1210, payment gateway computer system 140applies its private key to encrypted random key 1160 contained withinreceived merchant capture request 915, thereby decrypting it andobtaining a cleartext version of random key RK-3 1140. In function block1215, payment gateway computer system 140 applies random key RK-3 1140to encrypted combined block 1150, thereby decrypting it and obtaining acleartext version of combined block 1130. It will be recalled thatcombined block 1130 comprises basic capture request 1110, a copy ofmerchant computer system's 130 encryption public key certificate 1115and a copy of merchant computer system's 130 signature public keycertificate 1120, as well as merchant digital signature 1125.

[0141] In function block 1220, payment gateway computer system 140verifies merchant computer system's 130 encryption public keycertificate 1115 and merchant computer system's 130 signature public keycertificate 1120.

[0142] Payment gateway computer system 140 performs this verification bymaking a call to the certification authorities associated with eachcertificate. If verification of either certificate fails, paymentgateway computer system 140 rejects the capture request.

[0143] In function block 1225, payment gateway computer system 140validates merchant digital signature 1125. Payment gateway computersystem 140 performs this validation by calculating a message digest overthe contents of the combined basic capture request 1110, the encryptionpublic key certificate 1115 and the signature public key certificate1120. Payment gateway computer system 140 then decrypts digitalsignature 1125 to obtain a copy of the equivalent message digestcalculated by merchant computer system 130 in function block 1020. Ifthe two message digests are equal, the digital signature 1125 isvalidated. If validation fails, payment gateway computer system 140rejects the capture request.

[0144] In function block 1230, payment gateway computer system 140applies its private key to encrypted random key RK-2 790 containedwithin received merchant capture request 915, thereby decrypting it andobtaining a cleartext version of random key RK-2 775. In function block1235, payment gateway computer system 140 applies random key RK-2 775 toencrypted capture token 780, thereby decrypting it and obtaining acleartext version of capture token 770.

[0145] In function block 1240, payment gateway computer system 140verifies that a proper transaction is being transmitted between capturetoken 780 and capture request 1110. A capture token contains data thatthe gateway generates at the time of authorization. When theauthorization is approved, the encrypted capture token is given to themerchant for storage. At the time of capture, the merchant returns thecapture token to the gateway along with other information required forcapture. Upon receipt of the capture token, the gateway compares amessage made of the capture request data and the capture token data andtransmits this information over a traditional credit/debit network. Ifan improperly formatted transaction is detected, payment gatewaycomputer system 140 rejects the capture request.

[0146] In function block 1245, payment gateway computer system 140determines the financial institution for which capture is requested byinspection of basic capture request 1110. Payment gateway computersystem 140 contacts the appropriate financial institution using a securemeans, e.g, a direct-dial modem-to-modem connection, or a proprietaryinternal network that is not accessible to third parties, and usingprior art means, instructs a computer at the financial institution toperform the requested funds transfer.

[0147] Payment Capture Response Generation

[0148] Function blocks 1250 through 1285 depict the steps of generatingand transmitting a payment capture request response. FIGS. 13A through13F depict views of the payment capture response and its componentparts.

[0149] In function block 1250, payment gateway computer system 140creates a basic capture response 710. The basic capture request is adata area that includes all the information to indicate whether acapture request was granted or denied. FIG. 13A depicts basicauthorization request 1310.

[0150] In function block 1255, payment gateway computer system 140combines basic capture response 1310, and a copy of its signature publickey certificate 1320. Payment computer system 140 calculates a digitalsignature 1325 for the combined contents of the combined block 1330comprising basic capture response 1310 and the signature public keycertificate 1320, and appends the signature to the combination of thecombined basic authorization request 1310 and the signature public keycertificate 1320. The payment gateway computer system calculates digitalsignature 1325 by first calculating a message digest over the contentsof the combined basic capture response 1310 and signature public keycertificate 720. The message digest is then encrypted using the merchantcomputer system's 140 digital signature private key, thus forming adigital signature.

[0151]FIG. 13B depicts the combined block 1330 formed by function block1255 and containing basic capture request 1310, the signature public keycertificate 1320, and digital signature 1325.

[0152] In function block 1260, payment gateway computer system 140generates a symmetric random encryption key 1340, denoted as RK-4. FIG.13C depicts random encryption key RK-4 1340.

[0153] In function block 1275, payment gateway computer system 140encrypts combined block 1330 using random encryption key RK-4 1340 toform encrypted combined block 1350. FIG. 13D depicts encrypted combinedblock 1350. The encryption state of encrypted combined block 1350 isgraphically shown by random key lock 1355, which indicates thatencrypted combined block 1350 is encrypted using random key RK-4 1340.

[0154] In function block 1275, payment gateway computer system 140encrypts random encryption key RK-4 1340 using the public key ofmerchant computer system 130 to form encrypted random key RK-4 1360.FIG. 13E depicts encrypted random key RK-4 1360. The encryption state ofencrypted random key 1360 is graphically shown by merchant public keylock 1365, which indicates that encrypted random key 1360 is encryptedusing the merchant public key.

[0155] In function block 1280, payment gateway computer system 140concatenates encrypted combined block 1350 and encrypted random key RK-41360 to form merchant capture response 925. FIG. 13F depicts merchantcapture response 925 comprising encrypted combined block 1350 andencrypted random key RK-4 1360. In function block 1285, payment gatewaycomputer system 140 transmits merchant capture response 925 to merchantsystem 130.

[0156] Payment Capture Response Processing

[0157]FIG. 14 depicts the detailed steps of processing a payment captureresponse. In function block 1410, merchant computer system 130 appliesits private key to encrypted random key RK-4 1360 contained withinreceived merchant capture response 925, thereby decrypting it andobtaining a cleartext version of random key RK-4 1340.

[0158] In function block 1420, merchant computer system 130 appliesrandom key RK-4 1340 to encrypted combined block 1350, therebydecrypting it and obtaining a cleartext version of combined block 1330.It will be recalled that combined block 1330 comprises basic captureresponse 1310, a copy of payment gateway computer system's 140 signaturepublic key certificate 1320, as well as payment gateway digitalsignature 1325.

[0159] In function block 1430, merchant computer system 130 verifiespayment gateway computer system's 140 signature public key certificate1320. Merchant computer system 130 performs this verification by makinga call to the certification authority associated with the certificate.If verification of the certificate fails, merchant computer system 130concludes that the capture response is counterfeit and raises an errorcondition.

[0160] In function block 1440, merchant computer system 130 validatespayment gateway digital signature 1325. Merchant computer system 130performs this validation by calculating a message digest over thecontents of the combined basic authorization request 1310 and thesignature public key certificate 1320. Merchant computer system 130 thendecrypts digital signature 1325 to obtain a copy of the equivalentmessage digest calculated by payment gateway computer system 140 infunction block 1255. If the two message digests are equal, the digitalsignature 1325 is validated. If validation fails, merchant computersystem 130 concludes that the authorization response is counterfeit andraises an error condition.

[0161] In function block 1450, merchant computer system 130 storescapture response for later use in by legacy system accounting programs,e.g. to perform reconciliation between the merchant operating merchantcomputer system 130 and the financial institution from whom payment wasrequested, thereby completing the transaction.

[0162] The system of the present invention permits immediate deploymentof a secure payment technology architecture such as the SET architecturewithout first establishing a public-key encryption infrastructure foruse by consumers. It thereby permits immediate use of SET-complianttransaction processing without the need for consumers to migrate toSET-compliant application software.

[0163] All publications and existing subsystems mentioned in thisspecification are hereby incorporated by reference to the same extent asif each individual publication or existing subsystem were specificallyand individually indicated to be incorporated by reference.

[0164] While various embodiments of a preferred embodiment have beendescribed above, it should be understood that they have been presentedby way of example only, and not limitation. Thus, the breadth and scopeof a preferred embodiment should not be limited by any of the abovedescribed exemplary embodiments, but should be defined only inaccordance with the following claims and their equivalents.

What is claimed is:
 1. A method for initiating secure communicationbetween a first and a second computer connected to a network forreceiving and transmitting payment information, comprising the steps of:(a) establishing a communication between said first and said secondcomputer via said network; (b) identifying an encryption procedure and adecryption procedure utilized by said first and said second computer;(c) transmitting encrypted payment information from said first computerto said second computer; (d) receiving said encrypted paymentinformation at said second computer and decrypting the paymentinformation utilizing the decryption procedure; and (e) repackaging saidpayment information to comply with a third party secure protocol forfurther payment processing.
 2. The method as recited in claim 1,including the step of utilizing the Internet for transmittinginformation between said first and said second computer systems.
 3. Themethod as recited in claim 1, including the step of transmitting fromthe second computer system to a third computer system for authorizing ordenying credit in the payment processing.
 4. The method as recited inclaim 1, wherein the secure third party protocol is a Secure ElectronicTransaction protocol.
 5. A method for initiating secure communicationbetween a first and a second computer connected to a network forreceiving and transmitting payment information, comprising the steps of:(a) obtaining client information for use in said secure communicationbetween a first and a second computer; (b) establishing a communicationbetween said first and said second computer via said network; and (c)repackaging said payment information to comply with a third party secureprotocol for further payment processing.
 6. The method as recited inclaim 5, including: (d) transmitting encrypted payment information fromsaid first computer to said second computer; (e) receiving saidencrypted payment information at said second computer and decrypting thepayment information utilizing the decryption procedure; and (f)performing further payment processing on said decrypted information. 7.The method as recited in claim 5, wherein said client information isobtained via a telephone, fax machine or electronic mail.
 8. The methodas recited in claim 5, wherein an electronic signature is utilized toauthenticate payment processing.
 9. The method as recited in claim 7,wherein said client information is obtained via a secure general purposeprotocol.
 10. The method as recited in claim 5, further comprisesreversing previous payment transactions.
 11. Apparatus for initiatingpayment in a computer under the control of software with an attacheddisplay and an input device connected to a network for receiving andtransmitting network information, comprising: (a) means for establishinga communication between said first and said second computer via saidnetwork; (b) means for identifying an encryption procedure and adecryption procedure utilized by said first and said second computer;(c) means for transmitting encrypted payment information from said firstcomputer to said second computer; (d) means for receiving said encryptedpayment information at said second computer and decrypting the paymentinformation utilizing the decryption procedure; and (e) means forrepackaging said payment information to comply with a Secure ElectronicTransaction protocol for further payment processing.
 12. The apparatusas recited in claim 11, including means for utilizing the Internet fortransmitting information between said first and said second computersystems.
 13. The apparatus as recited in claim 12, including means fortransmitting from the second computer system to a third computer systemfor authorizing or denying credit in the payment processing.
 14. Anapparatus for initiating secure communication between a first and asecond computer connected to a network for receiving and transmittingpayment information, comprising: (a) communication hardware utilized bya client to communicate information for use in said secure communicationbetween a first and a second computer; (b) a computer under the controlof software which establishes secure communication between said firstand said second computer via said network; and (c) a computer under thecontrol of software which repackages said payment information to complywith a third party secure protocol for further payment processing.
 15. Acomputer program embodied on a computer-readable medium for effectingpurchase transactions by a customer system at a merchant system andeffecting payment for said transactions by a payment system, comprising:(a) a code segment for controlling secure communication of a purchaserequest from said customer system to said merchant system, includingproviding payment information from said customer system to said merchantsystem; (b) a code segment for controlling secure processing of saidpayment information by said merchant system to generate a paymentauthorization request and securely transmit said payment authorizationrequest from said merchant system to said payment system; (c) a codesegment for controlling the secure processing of said paymentauthorization request by said payment system to generate a paymentauthorization response authorizing said purchase and securely transmitsaid payment authorization response to said merchant system pursuant towhich said merchant system fills said purchase request; (d) a codesegment for controlling the secure processing of said paymentauthorization response by said merchant system to generate a paymentcapture request and securely transmit said payment capture request tosaid payment system; (e) a code segment for controlling the secureprocessing of said payment capture request by said payment system togenerate a payment capture response authorizing payment and transmitsaid payment capture response to said merchant system; and (f) a codesegment for controlling the secure processing of said payment captureresponse by said merchant system to effect payment to the merchantsystem for filling said purchase request.
 16. A computer programembodied on a computer-readable medium as recited in claim 15, whereinsaid secure protocol is a Secure Electronic Transaction protocol.
 17. Acomputer program embodied on a computer-readable medium as recited inclaim 15, wherein said secure protocol is a Secure TransactionTechnology protocol.
 18. A computer program embodied on acomputer-readable medium as recited in claim 15, wherein said secureprotocol is a Secure Electronic Payments Protocol.
 19. A computerprogram embodied on a computer-readable medium as recited in claim 15,wherein said information includes payment administration information.20. A computer program embodied on a computer-readable medium forinitiating payment in a computer under the control of software with anattached display and an input device connected to a network forreceiving and transmitting network information, comprising: (a) a codesegment for establishing a communication between said first and saidsecond computer via said network; (b) a code segment for identifying anencryption procedure and a decryption procedure utilized by said firstand said second computer; (c) a code segment for transmitting encryptedpayment information from said first computer to said second computer;(d) a code segment for receiving said encrypted payment information atsaid second computer and decrypting the payment information utilizingthe decryption procedure; and (e) a code segment for repackaging saidpayment information to comply with a secure protocol for further paymentprocessing.
 21. A computer program embodied on a computer-readablemedium for effecting purchase transactions by a merchant computer systemand payment for said transactions by a payment computer system,comprising: (a) a code segment controlling communication between saidcustomer and said merchant computer system for effecting purchaserequests, including providing payment information from said customer tosaid merchant computer system; and (b) a code segment controlling securecommunication between said merchant computer system and said paymentcomputer system for effecting operation on said payment information bysaid merchant computer systems to obtain administration information fromsaid payment computer system to said merchant computer system pursuantto which said merchant computer system completes said purchase request.